REPUBLIQUE 



F R A N Q A 



I^PI 



ri.i/wo4/ u 1/00 

0 1 AQUT 2003 



NATIONAL DS 
LA PROPRIBTE 
INDUSTRIBLLB 



RECEIVED 

2 6 AUG 2003 



WIPO PCT 



10 DiiC2004 



BREVET D ' I Ny E N T I O N 



CERTIFICAT D'UTILIT^ - CERTIFICAT D'ADDITION 



COPIE OFFICIELLE 



Le Directeur general de l^lnstitut natidnal de la prbpriete 
industrielle certifie que le document ci^nnex^ est la cople 
certifi^e confornne d'une demande de titrd de propriete 
industrielle deposee S IMnstitut v,, ■ r i /; : 



I ■ 

1. 1 



Fait a Paris, le . 



n 6 A m m 



PRIORITY 
DOCUMENT 

<!TiRMnTED OR TRANSMITTED IN 
.oSiSS^WTTH RULE 17.Ka) OR (b) 



Pour !e Directeur general de IMnstitut 
national de ia propri&t^ industrielle 
Le Chef du D6partement des brevets 




Martine PLANCHE 



Best Available Copy - 



SIEGE 

INSTITUT 26br$,niedeSaintPeter8bourg 
».^.^.... 75800 PARIS cedw 08 

NATIONAL DE T6l6phon8 : 33 (0)1 53 04 53 04 
LA PROPRIETE TilScople : 33 (0)1 53 04 45 23 
E www.Inplfr 



I nu 19 AVRIL 19S1 




BREVET DiMVENTION 
CERTiFICilA'UTlLITg 



mm 



N* 11354*01 



26 bis. mo do Saint Pctcrebourg 
75800 Paris Cedex 08 

T^l^phone : 01 53 04 53 04 TOecopie : 01 n2 94 86 54 



Codo do ia propridt^VRtoc^oHc - Llvro VI 

REQUETE EN DfUVRANCE 1/2 



REWSE 0F5 PJFCTS 
DATE 

i1 JU5M 2002 
75 IN PI PARIS B 

iNATW^LAnRmUKPARnNPI Ue£:^ ff t/O 

I DATE OE OEPOr ATTRlBUte 



1 1 JUIN 2002 



Get Imprlmfe est a rernplir Hsfbtement a I'encre noire 
M NOM ET AORESSE OU OEMANDEUR OU DU MANDATAIRE 
A QUI LA CORRESPONDANCE DOIT STRE ADRESS& 

■ COMPAGNIE FINANCIERE ALCATEL 
Departement PI 
Josiane EL MANOUNI 
30 avenue Kleber 
75116 PARIS 



C6 



i Vos references pour ce dossier b 


i Confirmation d'un d6p8t par t§l6cople □ N« attrifcue par I'lMPI & la telecop're 


1 M MftTURE DE LA DEMANDE 


Cochez rune des 4 cases suivantes 


1 Demande de brevet . 


a 


1 Demande de certificat d'utilite 


□ 


Demande divisionnaire 

Dmamk' tk hmv( imUak 
of{ <i::rmn(Ji* th cutiifical dtdiiU^ inUiak 


□ 

f4« nsfft \ f 1 1 


Transformation d'une demande de 
brevet europten l)manilv<k hmvl imiwk 


Date 1 / / 1 



TITRE OE UlUVEflTlOW (200 caractSros ou c$pac«s maximum) 

^ROCEDE POUR SUPPORTER DU TRAFIC TEMPS REEL DANS UN SYSTEME DE 
RADIOCOMMUNICATIONS MOBILES 



DECLARATION DE FRIORITE 
OU REQUETE DU BENEFICE DE 
LA DATE DE DEPOT D'UWE 
DEIUtANDE ANT^RIEURE FRANQAISE 



Pays OU organisation 
Date I / / 



Pays OU organisation 
Date 1 L 1— 



Pays OU organisation 
Date I / t— 



Q S'il y a d'autres pilorit6sy cochez ta case et trtllisez r imprime ctSMlte» 



DEMANDEUR 



□ S'll y a d'aitlres demandeurs, cochez la case et utlRsez rimprlm6 «Sufte» 



Nom oil denomination sociale 



EVOLIUM S.A.S. 



Prenoms 



Forme juddique 



N** SIREN 



Societe par Actions Simplif lees 

4. 3 2 a 4 1 1 4 41 



Code APE-NAF 



Adresse 



Rue 



12, rue de la Baume 



Code postal et ville 



75008 1 PARIS 



Pays 



Nationalite 



FRANCE 
Frangaise" 



W dD tet6phone (/mv/fc////) 



de tdlecoplD (fmiitaiip 



Adresse electronique fjaadhitifi 




IC3IIMD1IIUI 



REQU^ EN D&IVRANCE V% 




DATE 

Lieu JUIN 2002 
75 INPI PARIS B 

N* D-tNREGlSTRCMCNT Q 7 i 7 3 
NATIONAL ArmiBU^ PAR L*e*PI ^ 


• 

Vr 


Vos references pour ce dossier : 

(/(hiilfniifi 


1 04782/MA/NMND/rPM 






Nom 


EL MANOUNI 


Pr^nom 


Josiane 


Cabinet ou Socicte 


Compagnie Financiere Alcatel 


N **de pouvoir permanent et/ou 
de lien contractuei 


PCs 9799 


Adrosse 


Rue 


30 Avenue Kleber 


Code postal et vllle 


75116 1 PARIS 


N** de leleplio 


ne ffacidUiiifi 




N*" de telccopie {JaadUiiifj 




Adresse elcctronique ifaaiiUiUf* 




\ Q INVENITEUR (S) 




Les invenleurs sent les demandeurs 


\K Non Dans c© casfournfr une designation d'lnventeur{s) sieparde 


\ ^ RAPPORT DE RECHERCHE 


Unlquement pour une demande de brevet (y comprls dSmston et transformation) 


I Etablissement imm^dfat 
ou etablissement differe 


El 

□ 


Paiement echelonn^ de la redevance 


Paiement en trofs versements, uniquement pour les personnes physiques | 

□Oui 1 
EiNon 


i m REDUCTI0S9 DU TAUK 
DES REDEVANCES 


Uniquement pour les personnes physiques 

□Requise pour la premiere fois pour cette Invention (Johuir^ mi twis de imHmimsmm) \ 
ORequise anterieurement a ce depot (joimhy rme l o/w cie iu iivcisian (tadmhsioti 






Si vous avez utilise rimprim^ «$uite)>, 
indiquez le notnbre de pages jointes 


\ 


'■■ M SIGNATURE MMJ-SS^S^^IJgC 

1 )9MDU WAWOATAIRE Joslane ELrWIANOUNl / LC 40 B 
(Nom et quality du signataire) 


VISA DE LA PRgl^ECTURE 
OU DEUiHPi 

M. MARTIN 



La loi n"78-17 du 6 janvier 1978 relative d llnformatique, aux fichters et aux fibertes s'applique aux rtponses faKes a ce formulaire. 
Elle garantit un droit d'accds et de rectification pour les donntes vous concernant aupres de I'lNPl. 



PROCEDE POUR SUPPORTER DU TRAFIC TEMPS REEL DANS UN SYSTEMS 
DE RADIOCOMMUNICATIONS MOBILES 

La pr^sente invention concerne d'une manifere gSnerale les sysf&mes de 
radiocommunications mobiles* 
5 D'une maniere g^n6rale, ces systdmes font I'objet de normalisation, et pour 

plus d'informations on pourra se r6f6rer aux normes correspondontes, publiees par 
les organismes de normalisation correspondents. 

D'une manifere g§n6rale, dans ces systemes, on peut distinguer differents 
types de services, en fonction de la qualite de service requise. Notamment, on peut 

10 distinguer des services temps reel, correspondent a du trafic sensible aux delais de 
transfert (tel que notamment la voix, ou encore du trafic a flux continu ou 
« streaming »), et des services non temps reel, correspondant a du trafic non sensible 
aux delais de transfert (tel que notamment le transfert de donnees). 

D'une maniere generate, dans ces systemes, on peut aussi distinguer 

15 differents types de services, selon les techniques utilisees pour les supporter. On peut 
ainsi distinguer les services en mode circuit et les services en mode paquet. En mode 
circuit, le trafic est transporte dans des ressources ou canaux dedies alloues en 
permanence a un utilisateur pour la duree d'un appel. En mode paquet, le trafic est 
transporte dans des ressources ou canaux portages entre plusieurs utilisateurs. Le 

20 mode circuit permet ainsi de garantir les delais de transfert pour chaque utihsateur , 
mais ne permet pas une utilisation efficace des ressources disponibles pour 
I'ensemble des utilisateurs. Au controire, le mode paquet permet une utilisation 
efficace de I'ensemble des ressources disponibles, mais ne permet pas de garantir 
les delais de transfert. Le mode circuit et le mode paquet se differencient non 

25 seulement par des techniques differentes d'allocation de ressources, mais aussi par 
des architectures de protocoles differentes, 

Les systdmes de deuxieme generation, de type GSM (« Global System for 
Mobile communications ») ont plutdt ete con5us initialement pour supporter du trafic 
temps reel (essentiellement de la voix) en mode circuit. Des fonctionnalites 

30 supplementaires ont ensuite ete introduites dans ces syst^mes, correspondant a la 
fonctionnalite GPRS (« General Packet Radio Service »), pour leur permettre de 
supporter du trafic non temps reel en mode paquet. 
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L'architecture generale des systemes de radiocommunications mobiles est 
rappel6e sur la figure 1 , elle comporte essentiellement : ^ 
un reseau d'acces radio 1, ou RAN (pour « Radio Access Network »), 
un coeur de reseau 4, ou CN (pour « Core Neiwork »). y 
5 Dans cette architecture generale, le RAN est form6 de stations de base 2 et 

de controleurs de stations de base 3. II est en relation d'une part avec des terminaux 
mobiles via une interface 6 appel^e aussi interface radio, et d'autre part avec le CN 
4 via une interface 7. Le CN 4 est en relation avec des reseaux exterieurs, non 
illustrSs specif iquement, tels que PSTN (« Public Switched Telephone Network »), PDN 
10 (« Packet data Neiwork »), ...etc. 

L'architecture g6n6rale des systemes de deuxteme generation de lype GSM 
est rappelee sur la figure 2. Dans ces systdmes, le RAN est appele BSS ("Base Station 
Subsystem"), les stations de base sont appelees BTS ("Base Transceiver Station"), les 
controleurs de stations de base sont appeles BSC ("Base Station Controller"), et les 
15 terminaux mobiles sont appeles MS (« Mobile Station »). Les fonctionnalites propres 
aux services en mode paquet sont en general supportees par une entite particuliere 
appelee PCU (« Packet Control Unit »), non illustree specifiquement, prevue en 
general dans le BSS, 

Dans les systemes de deuxieme generation de type GSM, le CN comporte: 
20 - pour le mode circuit, des entites de type 2G-MSC (ou 2G est utilise pour 

« 2""* Generation » et MSC est utilise pour « Mobile Switching Center »), 
pour le mode paquet, des entites de type 2G-SGSN (ou 2G est utilise 
pour « 2"^^ Generation » et SGSN est utilise pour « Serving GPRS Support 
Node»). 

25 Ainsi, dans les systemes de deuxieme generation de type GSM, I'interface 7 

comporte une interface appelee interface «A» vers les entites de type 2G-MSC, et 
une interface appelee interface « Gb » vers les entites de type 2G-SGSN. 

Les systemes de type GERAN (« GSM EDGE Radio Access Network », oCi 
EDGE est utilise pour « Enhanced Data rates for GSM Evolution ») correspondent a 

30 des evolutions des systemes de type GSM, visant a offrir des services de troisieme 
generation, aussi bien pour des applications temps reel que pour des applications 
non temps reel. Le but est notamment de pouvoir supporter des services de type IMS 
(« IP Multimedia Sub-system »,oCi IP est utilise pour « Internet Protocol »). 
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Pour cela, ii a initialement 6te propose d'aligner les services offerts par les 
systemes de type GERAN sur ceux offerts par les systfemes de troisieme generation de 
type UMTS (« Universal Mobile Telecommunication System ») en connectant des BSS 
de type GERAN au CN 3G via les interfaces lu, lesdites interfaces etant utilisees pour 
5 connecter KUTRAN (pour « UMTS Terrestrial Radio Access Network) au CN 3G. 

L'architecture des systSmes de troisieme generation de type UMTS est 
rappele sur la figure 3. Dans ces sytfemes, le RAN est appele UTRAN , les stations de 
base sont appel6es Node B, les contr6leurs de stations de base sont appeles RNC 
(« Radio Network Controller »), et les terminaux mobiles sont appeles UE (« User 
10 Equipment »). 

Dans les syf^mes de troisieme generation de type UMTS, le CN comporte: 
pour le mode circuit, des entites de type 3G-MSC (oO 3G est utilise pour 
« 3"^ Generation » et MSC est utilis6 pour « Mobile Switching Center »), 

- pour le mode paquet, des entites de type 3G-SGSN (ou 3G est utilise 
15 pour « 3*^ Generation » et SGSN est utilise pour « Serving GPRS Support 

Node»). 

Ainsi, dans les systemes de troisieme generation de type UMTS, I'interface 7 
comporte una interface appelee interface « lu-CS » vers les entites de type 3G-MSC, 
et une interface appelee interface « lu-PS » vers les entites de type 3G-SGSN. 

20 L'architecture initialement proposee pour les sytemes de type GSM/GERAN 

est rappelee sur la figure 4. II a ainsi ete propose d'introduire dans les systemes de 
type GSM/GERAN, en plus des interfaces « A » et « Gb » existantes, une interface de 
type « lu-CS » vers des entites de type 3G-MSC et une interface de type « lu-PS ».vers 
des entites de type 3G-SGSN. 

25 Cependant, il est maintenant reconnu qu'une telle approche necessite des 

adaptations complexes et couteuses, notamment dans les protocoles radio de 
couches 2 et 3, 

C'est pourquoi une autre approche a maintenant 6t6 proposee, qui consiste 
a supporter les memes services que ceux supportes au moyen des interfaces « lu- 
30 CS », « lu-PS » mais au moyen des interfaces existantes « A », « Gb ». Le but est 
notamment de pouvoir supporter des services de type IMS (« IP Multimedia Sub- 
system » ) via I'interface « Gb ». Pour memoire, aujourd'hui I'interface « Gb » est 
seulement capable de supporter des sen/ices non temps reel (eventuellement du trafic 
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CI flux continu ou « streaming »), et des services temps reel peuvent seulement Stre 

support6s via ^interface « A ». ^ 

D'une manidre g6n6rale, cette derni^re approche inclut les ameliorations 
suivantes^ en vue de foire evoluer le mode dit « A/Gb » vers un mode dit « A/Gb+ »: ^, 
5 - flux de donn^es multiples et en parallele entre BSS et MS^ 

transfert intercellulaire (ou « handover ») pour des services temps reel en 
mode paquet, 

support de services temps reel par la partie radio (ou RAN), 
support de services temps r6el par la parKe r6seau (ou CN), 

10 - support de services IMS, 

amelioration des mecanismes de s6curit6- 
Jusqu'a present, la seule proposition pour le support de services temps reel 
en mode paquet sur I'interface « Gb » a ete de pr^voir un transfert intercellulaire 
ou « handover » pour les services en mode paquet. On rappelle que les procedures 

15 de transfert intercellulaire ou « handover » sont propres au mode circuit, Selon ces 
procedures, des ressources sont reservees dans une nouvelle cellule alors qu'une 
station mobile est encore connectee a une ancienne cellule, ce qui permet, au prix 
d'une certaine complexite, de garantir les delais de transfert. Au contraire, les 
procedures de re-selection de cellule sont propres au mode paquet. Selon ces 

20 procedures, des ressources ne sont allouees a une station mobile dans une nouvelle 
cellule que lorsque la station mobile est connectee a la nouvelle cellule, ce qui 
simplifie les procedures mais ne garontit pas les delais de transfert. 

La proposition mentionnee ci-dessus permet d'introduire pour le mode 
paquet des mecanismes similaires 6 ceux utilises dans les procedures de transfert 

25 intercellulaire ou « handover » pour le mode circuit. De plus, des procedures ont et6 
proposees pour permettre 6 une station mobile de reporter regulierement des 
mesures radio au r6seau en vue de permettre a ce dernier de selectionner une 
nouvelle cellule, comme dans le mode circuit. Pour cela, une nouvelle combinaison 
de canaux sur interface radio a ete proposee, notamment dans le document « Tdoc 

30 G2-020553, Agenda Item 5.3, 3GPPTSG GERAN WG2 Sophia-Antipolis, France, 
27-31 May 2002 ». Cette nouvelle combinaison consiste en un canal alloue pour un 
transfert de donn6es en mode paquet, ou canal PDTCH (« Packet Data Transfer 
Channel ») et en un canal de signalisation dedie en mode circuit ou canal SACCH 
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(« Slow Associated Control Channel »), ce dernier canal etant utilise pour un tel report 
de mesures radio de la station mobile vers le reseau. 

Ainsi que I'a obsen^e le dennandeur, une telle proposition a notamment les 
inconvenients suivants: 
5 - la station de base BTS et la station mobile MS doivent supporter une 

nouvelle combinaison de canaux, 

I'entite PCU (dans laquelle sont mises en oeuvre les fonctionnalites 
propres au mode paquet) doit traiter des reports de mesures et 
impl^menter des algorithmes de transfert intercellulaire ou « handover», 
10 - une nouvelle procedure doit §tre introduite sur I'interface radio pour 

supporter cette nouvelle combinaison, 

des probl^mes se posent au niveau de I'architecture de ces systfemes 
puisque le SACCH utiliseraJt un protocole de type LAPDm (« Link Access 
•Protocol for the Dm channel ») comma protocole de couche 2 alors que 
15 le canal de signalisation ossocie ou canal PDTCH, ou canal PACCH 

(« Packet Associated Control Channel »), utilise un protocole de t/pe 
RLC/AAAC, ces deux protocoles se terminant dans des noeuds de reseau 
differents (BTS pour LAPDm, PCU pour RLC/MAC). 
Par ailleurs, le canal PDTCH est un canal uni-directionnel alors que les 
20 sen/ices temps reel tendent a requerir des canaux bi-directionnels. Meme pour du 
trafic a flux continu ou « streaming », qui est prinicipalement une application uni- 
directionnelle, il semble difficile d'allouer le sens retour a d'autres utilisateurs, 
puisque ces utilisateurs genereraient tres vraisemblablement du trafic dans I'autre . 
direction, d'ou une preemption de resources pour du trafic de « streaming » d'une 
25 maniere inacceptable. 

La presente invention a notamment pour but de proposer une autre 
approche pour le support de services temps reel sur une interface de type « Gb », 
permettant notamment d'eviter tout ou partie des inconvenients mentionnes 
precedemment, ou encore necessitant tres peu d'adaptations par rapport aux 
30 architectures existantes. 

Un des objets de la presente invention est un procede pour supporter du 
trafic temps reel dans un systeme de radiocommunications mobiles comportant un 
r6seau d'acces radio et un coeur de reseau, ce proc6d6 6tant essentiellement tel que 
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du trafic temps reel supporte en mode paquet dans le coeur de reseau est supporte 
en mode circuit dans le r6seau d'acces radio. 

>* 

Suivant une autre caract6ristique, ledit support de trafic temps reel en mode 
circuit dans le reseau d'acces radio inclut une allocation de canaux dedi^s, ladite h 
5 allocation de canaux dSdies etant effectuee 6 la creation d'un contexte de flux paquet 
(PFC). 

Suivant une autre caracteristique, ledit contexte de flux paquet est cree dans 
le reseau d'acces radio. 

Suivant une autre caracteristique, ledit contexte de flux paquet contient des 
10 parametres de QoS a offrir par le reseau d'acces radio et negocies avec le coeur de 
reseau. 

Suivant une autre caracteristique, ledit trafic temps reel correspond a au 
moins un flux de media d'une session multimedia, 

Suivant une autre caracteristique, ladite allocation de canaux dedies utilise 
15 une procedure deallocation comportant un « paging » suivi d'un acces au reseau. 

Suivant une autre caracteristique, ladite allocation de canaux dedies utilise 
une procedure d'allocation directe. 

Suivant une autre caracteristique: 

une station mobile a laquelle des canaux dedies ont amsi ete alloues 
20 transmet au reseau des informations relatives a son identity, 

sur la base de ces informations, le reseau associe un contexte de flux 
paquet a cette station mobile, et , le cas echeant, une re-allocation de canaux 
dedies est effectuee en vue de satisfoire la qualite de service requise pour cette station 
mobile. 

25 Un autre objet de la pr6sente invention est un equipement de reseau d'acces 

radio pour systeme de radiocommunications mobiles, comportant des moyens pour 
mettre en ceuvre un tel proced6. 

Un autre objet de la pr6sente invention est un equipement de coeur de 
reseau pour syst6me de radiocommunications mobiles, comportant des moyens pour 
30 mettre en oeuvre un tel proced6. 

Un autre objet de la presente invention est une station mobile pour systeme 
de radiocommunications mobiles, comportant des moyens pour mettre en oeuvre un 
tel procede. 



104782/MA/NMND 



F:\SGlle\F 1 04782\PREMDEP\Fn\proielbr.doc 



D'autres objets et caracteristiques de la presents invention apparattront a la 
lecture de la description suivante d'un exemple de realisation, faite en relation avec 
les dessins ci-annexes dans lesquels: 

- la figure 1 est un schema destine a rappeler I'architecture g6n6rale d'un 
5 systems de radiocommunications mobiles, 

- la figure 2 est un schema destine 6 rappeler rarchitecture generale d'un 
systeme de deuxi^me g6n6ration de type GSM, 

- la figure 3 est un schema destin6 6 rappeler I'architecture generale d'un 
systeme de troisieme generation de iype UMTS, 

- la figure 4 est un schema destin6 a rappeler une architecture generale 
propos6e initialement pour un systeme de type GERAN, 

- les figures 5a et 5b sont des schemes destines a illustrer, par 
comparaison, devolution proposee par la presents invention pour 
^architecture g6n6rale d'un systeme de Iype GERAN, 

"•S - la figure 6 est un schema destine 6 illustrer un exemple de mise en 

oeuvre d'un procede suivant I'invention. 
La presente invention sugg^re d'utiliser les canaux et protocoles radio 
existants, utilises pour les services temps reel lorsque ceux-ci sont relay6s via le MSG. 
Au lieu d'utiliser des canaux partag6s (ou « shared channels ») pour echanger des 

20 unites de donndes ou PDUs (« Packet Data unit ») de/vers le SGSN, I'idee est d'utiliser 
des canaux d6di6s (ou « dedicated channels »). Si des services temps reel et non 
temps r6e\ doivent gtre supportes simultanement, les procedures DTM (« Dual 
Transfer Mode ») existantes peuvent Stre utilisees pour controler I'etablissement et le 
relachement des differents flux de donn6es. 

25 On rappelle brifevement que lo fonctionnalite DTM est une fonctionnalite 

permettant de supporter simultanement les deux types de services (en mode circuit et 
en mode paquet), pour les stations mobiles pouvant supporter simultanement ces 
deux types de services, en prevoyant une coordination par le BSS des ressources 
necessaires a chacun des modes. Pour une description detaillee de cette 

30 fonctionnalite, on pourra aussi se referer aux specifications correspondontes publiees 
par les organismes de normalisation, 

L' evolution proposee selon I'invention peut etre illustree par comparaison 
des figures 5a et 5b. Les equipements illustres sur les figures 5a et 5b sont ceux deja 
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pr6seni6s en relation avec la figure 2, a savoir BTS, BSC, MSG (ou 2G-MSC), SGSN 
(ou 2G-SGSN) ; de plus, la connexion entre un MSG et un reseau exterieur de type 
PSTN, via une entite de type G-MSC (« Gateway-MSG ») a ete illustree sur les figures 
5a et 5b; de mdme la connexion entre un SGSN et un r6seau exterieur de type PDN, 

5 via une entite de type GGSN (« Gateway GPRS Support Node») a ete illustree. Les 
interfaces « Abis » entre BTS et BSC, « Gn » entre SGSN et GGSN, et « Gi » entre 
GGSN et PDN ont egalement ete illustr^es. Le but 6tant notamment de pouvoir 
supporter des services de type IMS, dans la figure 5b, PDN a 6t6 remplace par IMS. 

Lo figure 5a correspond 6 une architecture dassique, dans laquelle les 

10 services temps r6el relay^s via un MSG sont transport's via des canaux dedi^s sur 
{'interface radio. 

La figure 5b correspond a une architecture selon ('invention, dans laquelle 
les services temps reel relay's via un SGSN sont transportes via des canaux d'dies 
sur {'interface radio. 

15 Dans I'architecture GSM existante, il est pr'vu deux types d'unit's pour 

traiter les deux types d'appels, en mode circuit et en mode paquet. Ces deux types 
d'unites peuvent ou non ^re int'gr'es physiquement dans un m§me 'quipement. 
L'unit6 charg'e de traiter les appels en mode paquet, ou PCU (« Packet Control 
Unit ») est en general prevue dans le BSS. 
20 Ainsi, generalement, il y a dans le BSS une unite connect'e 6 I'interface 

«A» et qui traite les appels en mode circuit, et une autre unit' connect'e 6 
I'interface « Gb » et qui traite les appels en mode paquet. Les appels en mode circuit 
sont transportes ou moyen de canaux d'di's, c'est-a-dire alloues en permanence 
pour la duree de I'oppel, alors que les appels en mode paquet sont transportes au 
25 moyen de canaux portages, c'est-a-dire portages avec d'autres utilisateurs. 

L'invention propose de supporter des services temps reel dans I'unit' 
connectee a I'interface « Gb » a trovers les fonctions suivantes : 

- support de re-localisation de lien « Gb » lorsque la station mobile 
change de cellule et lorsque la nouvelle cellule est contr6lee par un BSS 
30 different du BSS contrdlont I'ancienne cellule, et lorsqu'une session 

temps r'el est en cours a trovers I'interface « Gb », 



r 
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- support de procedure de PFC (« Packet Flow Context ») pour negocier les 
parametres de QoS avec le SGSN lors d'une activation/modification de 
contexte PDP, 

- Lorsqu'un PFC est cree/modifie pour un flux de donn^es temps reel, 
Tunite connectee a I'interfoce « Gb » declenche 
I'etablissement/modification d'un canal dedie, 

- les unit& de donnees temps reel regues de/vers P interface »Gb » sont 
transportees sur I'interfoce radio au moyen de canaux dedies, 
lorsqu'un « handover » est requis, les procedures et mecanismes 
existants definis pour les canaux dedi6s sont utilises ; la seule difference 
est que le MSC n'est pas informe ; au lieu de cela, I'unit6 connectee a 
I'interfoce « Gb » est inform6e, et assure si necessaire une re-localisation 
de lien « Gb ». 

Avant de d6crire un exemple de mise en ceuvre de la pr6sente invention, on 
rappelle tout d'abord les protocoles ou procedures propres aux systemes en mode 
paquet, ou aux architectures de type IMS, dans la mesure ou ils peuvent etre utiles a 
la description de cet exemple. 

Selon I'architecture en couches utilisee pour decrire les systemes en mode 
poquet, notamment de type GSM/GPRS, on distingue, sur I'interfoce radio entre MS 
et BSS: 

une premiere couche, ou couche physique, 

une deuxieme couche, ou couche liaison, elle-meme divisee en plusieurs 
couches: par ordre de niveaux croissants, MAC (pour « Medium Access 
Control » en anglais), RLC (pour « Radio Link Control » en anglais) et 
LLC (pour « Logical Link Control » en anglais). 
De meme, on distingue, sur I'interface « Gb » entre BSS et SGSN: 
une premiere couche, ou couche physique, 

une deuxieme couche, ou couche liaison, elle-m§me divisee en plusieurs 
couches : par ordre de niveaux croissants, « Frame Relay » (en anglais), 
BSSGP (pour « BSS GPRS Protocol» en anglais), et LLC (pour « Logical 
Link Control » en anglais), 
Des frames appelees trames LLC (ou « LLC frames » en anglais) sont 
formees, dans la couche LLC, a partir d'unites de donnees regues d'un niveau 
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superieur, ou couche reseau, via une couche d'adaptation ou SNDCP {« Subnelwork 
Dependent Convergence Protocol »). Dans les trames LLC ces unites de donnees sent 
appelees unites de donnees LLC-PDU (pour « LLC-Protocol Data Units »)• 

Les unites de donn6es LLC-PDU sont ensuite segmentees dans la couche 
5 RLC/MAC, de mani^re a former des blocs appeles blocs de donnees RLC (ou « RLC 
data blocks »). Les blocs de donnees RLC sont ensuite mis au format requis pour 
transmission sur I'interFace radio, dans la couche physique. 

En outre, des protocoles de signalisation sont prevus, notamment pour la 
gestfon des ressources radio ou RR (« Radio Resource Management »), la gestion de 
10 la mobilite pu MM (« Mobility Management»), la gestion de session ou SM (« Session 
Management»), le contrdle de lien logique ou LL (« Logical Link Control »), ...etc. 

On rappelle aussi que, selon le protocole de gestion de ressources radio, 
differents modes sont possibles pour une station mobile, en mode paquet : 

un mode dit « packet transfer mode », dans lequel des ressources sont 
"■5 allou6es temporairement, lorsque des donnees sont effectivement d 

transmettre au cours d'une communication, ces ressources formont un 
canal virtuel temporaire ou TBF (« Temporary Block Flow ») permetfant 
un transfert de donnees entre station mobile et reseau, pour un sens de 
transmission donn6, 

20 - un mode dit « packet idle mode », dans lequel oucun TBF n'est etabli. 

Par opposition, en mode circuit, le mode dans lequel des ressources sont 
allouees a une station mobile est appele « dedicated mode », ces ressources etant 
alors des ressources dediees allouees a la station mobile pour la duree de la 
communication. Dons le cas ou a la fois des ressources dediees et des ressources 

25 partagees sont allouees a la station mobile en meme temps, ladite station mobile se 
trouve en « dual transfer mode ». 

A sa mise en marche, une station mobile est aussi dite en mode veille, 
ou « idle mode ». 

En outre, selon le protocole de gestion de mobilite, on definit une procedure 
30 dite d' « attachement GPRS » (ou « GPRS Altach»), permettant a une station mobile de 
passer du mode « idle mode » a un mode dit « attache GPRS » (ou « GPRS 
attached »), dans lequel elle peut acc^der 6 des services GPRS. On definit aussi la 
procedure inverse de « GPRS Detach ». 
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Une station mobile en mode veille et non attochee GPRS communique avec 
le r^seau per Tintermediaire d'echanges de signalisation sur des canoux appel6s 
CCCH (« Common Control CHannel »). Une station mobile aitachee GPRS et en 
mode « packet idle mode » communique avec le reseou par I'intermediaire 
5 d'echanges de signalisation sur des canaux appel6s PCCCH (« Packet Common 
Control Channel ») si de tels canaux sont pr6vus dans la cellule consideree, sinon 
par les canaux CCCH. Une station mobile attach6e GPRS et dans le mode « packet 
transfer mode » communique avec le reseau par I'intermediarre d'echanges de 
signalisation sur des canaux appel6s PDCH (« Packet Data Channel »). 

10 On rappelle que le canal de donn6es PDCH inclut un canal de trafic ou 

PDTCH {« Packet Data Trafic Channel »), et un canal de signalisation ou PACCH 
(« Packet Associated Control CHannel »). 

On rappelle aussi que le canal CCCH inclut lui-meme un certain nombre de 
canaux tels que notamment un canal PCH (« Paging CHannel »). De m§me le canal 

15 PCCCH inclut lui-meme un certain nombre de canaux tels que notamment un canal 
PPCH (« Packet Paging CHannel »)• 

On rappelle aussi que lorsqu'une session doit Stre etobiie dans un systems 
tel que le GPRS, une procedure d'activation contextuelle de protocols de donnees en, 
mode paquet (ou PDP, pour « Packet Data Protocol ») doit etre lancee. Le contexte de 

20 PDP (ou « PDP context ») contient les informations necessaires au transfert des^ 
donnees entre MS et GGSN (informations de routage, profit de QoS, ...etc.). 

On rappelle aussi que dans une architecture de fype IMS, une signalisation 
relative au controle de session d'appel multimedia a jusqu'a present ete definie pour 
des technologies de type UMTS. Une telle signalisation comporte ainsi typiquement 

25 I'etablissement d'une connexion RRC entre une station mobile et un RAN, suivi de 
I'etablissement d'une porteuse UMTS pour transporter la signalisation relative au 
protocols SIP. Le protocole RRC, pour « Radio Resource Control » est defini dans la 
norms 3GPP TS 25.331. Le protocole SIP (« Session Initiation Protocol ») oinsi que le 
protocole SDP (« Session Description Protocol ») qui lui est lie ont ete definis par I'lETF 

30 (« Internet Engineering Task Force ») qui est I'orgonisme ds normalisation pour Is 
protocole Internet, ou IP (pour « Internet Protocol »). 

Les principales etapes d'une telle signalisation sont les suivantes, notees SI, 
S2, S3. Pour simplifier, on ne considere ici qu'un des trois segments en lesquels se 
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decompose le controle de session d'appel, en I'occurrence le segment qui va de I'UE 
appelant a son S-CSCF, les deux autres segments etont le segment qui va de I'UE ^ 
appele a son S-CSCF, et le segment qui relie les S-CSCF de I'UE appelant et de I'UE 
appele. On roppelie que les entites S-CSCF {« Sen/ing-Call Session Control ^ 
5 Function ») et P-CSCF (<c Proxy-Call Session Control Function ») sont des entit6s du 
reseau de coeur, en charge du controle de sessions d'appels multimedia. 

L'6tape SI correspond essentiellement 6 une etape preliminaire a 
l'6tablissement de session, 

L'etape SI utilise une procedure dite d'activation de contexte de protocole 
10 de donn6es en mode paquet, ou contexte PDF (ou « PDP Context», pour « Packet 
Data Protocol Context»), necessaire au transport de signalisation de controle de 
session multimedia. On rappelle qu'un contexte PDP comporte un ensemble de 
parametres de porteuse UMTS, tels que notamment des parametres de quality de 
service, ou QoS (pour « Quality of Service »), ...etc. Cette etape sera suivie 
15 ulterieurement d'une autre proc6dure d'activation de contexte PDP, necessaire au 
transport des donnees liees a la session multimedia elle-m§me. Ces deux contextes 
PDP concernant la meme adresse IP, I'etape SI sera aussi appelee procedure 
d'activation de contexte PDP primaire, 

L'etape SI comporte elle-m&me essentiellement les etapes suivantes, Dans 
20 une 6tape Sll, une requete d'activation de contexte PDP est transmise de I'UE au 
RAN, avec les parametres correspondants de qualite de service de bout en bout (ou 
« end-to~end QoS ») pour la porteuse UMTS de signalisation de niveau SIP, Dans une 
etape 512, le 3G-SGSN commande I'etablissement d'une porteuse d'acces radio (ou 
RAB, ou « Radio Access Bearer ») de sorte qu'un support soit disponible entre UE et 
25 3G-SGSN, repondant cux contraintes de qualite de service, Lorsque le RAN regoit 
une telle requete, aprfes un controle d'admission d'appel, il etablit une porteuse 
radio (ou RB, ou « Radio Bearer ») sur I'interface radio (etape SI 3) et une porteuse lu 
(ou « lu bearer ») sur I'interface « lu ». I'etablissement du RAB peut alors etre 
confirme (etape SI 4) et le contexte PDP active (etape SI 5), apres negociation avec le 
30 3G-GGSN (etape SI 6, SI 7). 

L'etape S2 correspond essentiellement a I'etablissement de la session 
multimedia au niveau du protocole SIP. Cette etape inclut une negociation permettant 
de determiner les caracteristiques pour la session en cours d'etablissement, Cette 
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negociation inclut notamment une negociation de codecs^ permettant de determiner 
une liste ou ensemble de codecs capables d'etre supportes en commun par les deux 
parties a I'oppel et autoris6s par tous les noeuds de r6seau intermediaires, pour cette 
session. 

5 On roppelle que les codecs determinent, oussi bien dans les stations mobiles 

que dans le r6seau d'acces radio (notamment dans les stations de base) ainsi que 
dons le coeur de reseau, comment r6aliser le codage source et le codage canal 
necessaires notamment a la transmission sur I'interface radio. Par exemple, pour le 
codage de parole, dans un systems de type GSM, il existe differents types de codecs: 

10 plein debit (ou FR, pour "Full Rate"), plain debit amelior6 (ou EFR, pour "Enhanced Full 
Rote"), demi-debit (ou HR, pour "Half Rate"), ou encore AMR (pour "Adaptive Multi- 
Rate coding"), ce dernier etant particulierement interessant en ce qu'il permet 
d'optimiser la quaiite de sei^vice (en Toccurrence en selectionnant a chaque instant, 
en fonction des conditions de transmission rencontrees, une combinaison optimale 

15 d'un codage source donne et d'un codage canal donne). Deux types de codec AMR 
existent : le codec a bande etroite « Narrowband AMR » et le codec 6 bande large 
« Wideband AMR ». Un codec de type « Wideband AMR » offre une quaiite de service 
encore meilleure mais necessite des debits radio plus importants. Le cas de parole 
n'est bien sOr qu'un exemple des differentes composantes, ou differents flux de 

20 media, formant une session multimedia. 

L'etape S2 comporte essentiellement les etapes suivantes. Une fois qu'un 
RB a ete etabli pour la signalisation SIP (au moyen de I'etape precedente 51), une 
premiere tQche consiste pour le client SIP 6 d6couvrir son P-CSCF. Ensuite, il devrq se 
declarer et.s'enregistrer aupr^s de son S-CSCF, ce qui fera appel a d'autres entites 

25 de coeur de reseau. Enfin, lors d'un etablissement de session, une requSte appelee 
« SIP Invite » est envoyee a la portie appelee via les entit6s P-CSCF et S-CSCF. Ce 
message contient un datagramme SDP qui indique pour chaque flux de media que 
I'UE appelant souhaite 6tablir, un certain nombre de parametres de media tels que : 
type de media, combinaison d'attributs de QoS, liste de codecs capables d'etre 

30 supportes pour cette session, ...etc. Les entites P-CSCF et S-CSCF associees a la 
partie appelante puis a la portie appelee effectuent alors un contrdle de service 
(selon des criteres propres ou r6seau) sur ces paramfetres. La partie appelee 
determine alors entre autre so propre liste de codecs capables d'Stre supportes pour 
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celte session, puis une liste de codecs copables d'etre supportes en commun par les 
deux parties, appelante et appelee, et retourne alors cette dernifere liste a la portie 
cppelante. La partie appelante determine alors quels flux de nn6dia devraient §tre 
utilises pour cette session, et quels codecs, dans cette liste, devraient etre utilises pour 
5 cette session. 

L'etape S3 correspond essentiellement d une fin d'etablissement de session, 
et comporte une etape deallocation de ressource, a partir des caracteristiques de flux 
de media (en terme d'attributs de QoS, de codec negocie, etc) ainsi determinees 
dans Tetape S2. 

10 L' etape S3 utilise aussi une procedure deactivation de contexte PDP, appelee 

aussi procedure deactivation de contexte PDP secondaire (pour la distinguer de la 
procedure d'activation de contexte primaire utilisee dans I'etape SI). L' etape S3 est 
semblable a i'etape SI, a ceci pres que les parametres de porteuse UMTS a etablir 
correspondent maintenont aux besoins determines dans I'etape S2. L' etape S3 

15 comporte elle-meme des etapes qui sont semblables a celles de la I'etape SI, et qui 
pour cette raison ne seront pas re-decrites. 

L' etape S3 comporte ainsi Ketablissement d'un RAB pour ce contexte PDP 
secondaire. Lorsque ce RAB est etabli, le RAN effectue un contr6le d'admission et 
accepte ou rejette I'appel. 

20 On rappelle par ailleurs que, d'une maniere generate, dans ces systemes, il 

est necessaire de pr6voir une gestion de la quality de service (ou QoS, pour « Quality 
of Service ») de mani&re a satisfaire les besoins des utilisateurs, en tenant compte 
d'une diff6renciation des applications et des utilisateurs, et tout en utilisant aussi 
efficacement que possible les ressources de transmission disponibles. 

25 D'une maniere gen6rale, cheque service est defini par des parametres ou 

attributs de qualite de service (tels que le debit binaire goranti, le d6lai de transfert, 
...etc.), I'ensemble de ces parametres ou attributs formant un profil de qualite de 
service. 

Pour le GPRS, la gestion de la quality de service a fait I'objet d'ameliorations 
30 entre les versions R97 et R99 de la norme. 

Dons la version R97 de la norme, seuls des services non temps reel peuvent 
etre offerts aux utilisateurs. Ainsi, dans le sens montant, la station mobile peut 
indiquer des parametres de QoS quand elle requiert I'etablissement d'un TBF (pour 
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« Temporary Block Flow ») dons le sens montanf, en utilisont une procedure d'acces 
dite en deux phases. Dans le sens descendant, choque LLC PDU regue du SGSN 
contient un element d'information appel6 « QoS Profile Information Element », 
donnant des informations limitees sur la qualite de service. Ces parametres peuvent 
5 §tre utilises par le BSS pour effectuer dans une certaine mesure une differenciation de 
services. 

Dans la version R99 de la norme, une nouvelle procedure, ou procedure de 
creation de « BSS Packet Flov^^ Contexb) a 6te introduite, definie notamment dans les 
specifications 3GPP TS 23,060 et 3GPP TS 08.18. Cette procedure autorise la 

10 negociation entre le SGSN et le BSS de tous les parametres de QoS 6 offrir pour le 
transfert de toute LLC- PDU se rapportant au PFC (« Packet Flow Context ») ainsi cree. 
Le SGSN peut aggreger le transfert de LLC-PDUs correspondent a plusieurs 
contextes PDP donnes (ou « PDP Context », ou PDP est utilise pour « Packet Data 
Protocol ») dans un meme PFC. Ceci est possible si les PDP Contexts aggreges ont 

15 des contraintes de qualite de service proches. Les parametres de QoS ainsi negocies . 
sont ceux definis dans la version R99 et contiennent beaucoup plus d'informations 
que le profil de QoS defini dans la version R97. lis contiennent en particulier toutes : 
les variables necessaires pour la definition d'un sen/ice temps reel, 

Le contexte de PDP (ou « PDP context ») cree lors de I'etablissement d'une • 

20 session de donnees contient les informations necessaires au transfert des donnees 
entre MS et GGSN (informations de routage, profil de QoS, ...etc.). Lorsqu'il active 
un contexte PDP, si la fonctionnalite PFC est implementee dans le BSS et le SGSN, ce 
dernier peut requerir des parametres de QoS du BSS qui peut negocier tout ou 
partie de ces parametres en fonction de so charge et de ses capacit6s. Ceci signifie 

25 que les donnees associees 6 un contexte PDP et done a une QoS donn6e sont bien 
identifiees non seulement dans le coeur de reseau CN mais aussi dans le reseau 
d'acces radio RAN. Ceci permet d'assurer que la QoS offerte pour le contexte PDP 
est negociee entre tous les noeuds de reseau, et il devient ainsi possible de garantir 
certains attributs de quality de service. II est ainsi possible d'obtenir qu'un debit 

30 binaire goranti ou un d6lai de transfert maximum soit offert, ce qui permet d'offrir 
des services temps reel. 

Pour supporter des applications temps reel il est necessaire que le BSS soit 
capable d'offrir le debit requis et aussi de transferer les LLC PDUs regues dans les 
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limites du delai de transfert maximum. Pour cela, il est necessaire qu'il y ait aussi peu 
que possible de mise en file d'ottente dans le BSS (on rappelle que la mise en file 
d'attente est propre au transfert utilise dans les systemes en mode paquet), et que les 
interruptions de transfert (dues notamment aux re-selections de cellule, comme 
5 rappele precedemment) soient aussi courtes que possible. Ceci requiert que le BSS 
connaisse tou jours les specifications de QoS pour le transferf de telles donnSes, ou en 
d'autres termes qu'il dispose d'un contexte contenant des informations de.profil de 
QoS associees. 

Selon la procedure de creation de « BSS Packet Flow Contexf», telle que 

10 specif lee notamment dons le document 3GPP TS 23.060, le SGSN peut a tout 
moment requerir la creation d'un contexte appele « BSS Packet Flow Context » (ou 
PFC), notamment iors de I'activation d'un contexte PDP. 

La figure 6 est un schema destine a illustrer un exempie de mise en oeuvre 
d'un procede suivant I'invention. 

15 On notera que la presente invention couvre aussi bien le cas d'un appel 

regu par la station mobile (ou « MT Call »/ pour « Mobile Terminating Call ») que le 
cas d'un appel 6mis par la station mobile (ou « MO Call », pour « Mobile Originating 
Call ») a trovers le domaine paquet (ou « PS domain »). Une etape dans ces 
differents scenarios est I'etablissement d'un canal dedie, sur creation d'un PFC. Les 

20 specifications 3GPP concernant I'IMS (23,228 et 24.228) definissent les differents flux 
pour I'etoblissement d'appel, et le but n'est pas ici de les rappeler. Dans tous les 
scenarios, une etape importante qui constitue plus porticulierement un des objets de 
la presente invention est I'etape de reservation de ressources, Dans le cas 
d'etablissement de session MO, ceci se produit entre I'envoi des messages « Final 

25 SDP » et « Resource Reservation successful)) . Dans le cas d'etablissement de session 
MT, ceci se produit opres que le message « Final SDP » ait ete regu de la partie 
appelante. 

On suppose qu'un contexte PDP pour la signalisation SIP est 6tabli et que le 
MS est dans le mode « Packet Idle Mode », lorsqu'une reservation de ressources est 
30 effectu6e (si un TBF est en cours, alors le premier etablissement de TBF ne sera pas 
effectue). 

Les etapes suivantes peuvent §tre mises en oeuvre: 
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(1) Le MS dedenche une activation de contexte PDP secondaire pour le flux 
de m6dia, dont les paramfetres de QoS ont ete negocies au niveau SIP. Pour cela, le 
MS requiert un TBF montant (ou UL TBF, pour « Uplink TBF ») sur des canaux 
portages. 

5 (2) Lorsque le SGSN regoit le message «ACTIVATE PDP CONTEXT REQUEST 

du MS, il cree le contexte PDP dans le SGSN et envoie alors un message CREATE BSS 
PFC sur ['interface Gb, afin de demander ou BSS de r6server les ressources radio 
necessaires pour le flux de media temps-r6el. 

(3) La QoS requise indique des coracteristiques de temps-r6el. II est ici 
10 propose d'autoriser le BSS a allouer des ressources dediees. Deux methodes ou 
procedures sont proposees dans le cas ou le BSS peut allouer de ielles ressources en 
correspondence avec la QoS requise: re-utiliser autant que possible les techniques 
exislantes en envoyant un « paging » au MS, ou introduire un nouveau message 
deallocation: On peut noter qu'a ce stade le MS est necessairement dans I'etai GMM 
15 READY puisqu'une LLC PDU dans le sens montant vient d'etre envoyee, contenont le 
message ACTIVATE PDP CONTEXT REQUEST. 

(3a) Dans une premiere procedure, le BSS genere un « paging » vers le MS. 
Dans l/etat actuel de la norme pour le mode A/Ch, un MS peut recevoir un « CS 
paging » (ou « paging » pour services en mode circuit) seulement si ce « CS paging » 
20 est regu du MSC. II est ici propose que le BSS genere un « paging » pour des services 
temps-r6el apres avoir re^u une requete du SGSN, Suivant I'etat radio du MS, le 
message de « paging » peut eire envoye soil sur des canaux de controle communs 
soit sur le PACCH d'un TBF en cours. Ceci serait similaire a un « CS paging », avec 
I'exception qu'une indication serait presente pour indiquer que ce « paging » vient du 
25 domaine PS (« Packet Switched ») ou mode paquet. Si un ou plusieurs TBF etaient en 
cours, le MS retournera aux canaux de contr6le communs et initiera une procedure 
d'acces al6atoire (« random access ») en demandant des ressources dediees (une 
autre option consisteraii en une amelioration des procedures de DTM (« Dual 
Transfer Mode ») de maniere a autoriser le MS a initier un acces d6di6 6 trovers le 
30 PACCH d'un TBF en cours). Le BSS allouera alors des ressources d6diees et le MS 
etabiira le lien de signalisation de couche 2. 

II est aussi propose de demander a la station mobile MS d'envoyer un 
message GPRS INFORMATION contenont I'identifiant TLLI {« Temporary Logical Link 
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Identifier ») propre d la station mobile MS. Ce message peut aussi contenir une 
trame LLC vide superposee (« piggybacked » en anglais) au message SABM. Le TLLI 
sera renvoye au BSS, de sorte que le BSS peut associer la connexion nouvellement 
etablie a la requete regue dans le message CREATE BSS PFC. Dans le cos oD les 
5 ressources allou^es ne correspondent pas a la QoS requise, un « handover » intra- 
cellulaire peut §tre effectue pour allouer des ressources en correspondence ovec la 
requete re^ue du SGSN (ou en correspondance avec la QoS n6gociee avec le SGSN) 
si de telles ressources sont disponibles, Le message GPRS INFORMATION peut etre 
envoy6 sur le canal ded\6 DCCH (« Dedicated Control Channel ») une fois etabii. On 

10 note que tout autre message contenant le TLLI du MS peut etre utilise. 

(3b) Dons une seconde procedure, on alloue directement au MS des 
resources dediees : un nouveau message pourrait etre introduit, evitant le besoin 
d'avoir a envoyer un « paging » au MS. Le BSS allouerait alors directement les 
ressources dediees, a trovers un nouveau message envoye sur les canaux de controle 

15 communs (MS dans le mode «. Packet Idle Mode ») ou sur le PACCH d'un TBF en cors 
(MS dans le mode « Packet Transfer Mode »). Le MS activera alors les nouvelles 
ressources (eventuellement en basculant vers le mode « RR Dual Transfer Mode » si 
un ou pisieurs TBF etaient en cours) et^etablira le lien de signalisation de couche 2. 
Comme dans la premiere procedure, le MS enverra un message GPRS 

20 INFORMATION contenant le TLLI, qui sera renvoye au BSS . Dans ce cos, les 
ressources allouees devraient etre en correspondance avec la QoS requise. 

(4) Le BSS envoie alors un acqufttement au SGSN pour la creation du PFC. II 
est a noter que dons le cas ou le BSS ne pourrait allouer des ressources permettant 
de realiser la QoS requise, il peut tout d'abord essayer de negocier les parametres 

25 de QoS, et si la negociation reussit, il peut alors effectuer I'etoblissement des canaux 
dedies. 

(5) L'activation de contexfe PDP est alors terminee (a trovers I'etoblissement 
d'un TBF, ou en utilisant le message GPRS INFORMATION, ou en utilisont un TBF 
existant s'il est toujours en cours), 

30 (6) L'etablissement de I'appel peut alors Stre termine au niveau SIP. 

Lorsque la session a commence, les PDU temps-r6el sont routees comme 

suit: 
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- dans le sens reseau vers MS : GGSN -> SGSN (Interface <c Gn »), SGSN 
->BSC (interface « Gb ») , BSC-^ BTS (Interface Abis), BTS -> MS 
(Interface radio) 

- dans le sens MS vers reseau : MS -> BTS (Interface radio), BTS BSC 
5 (Interface « Abis »), BSC SGSN (Interface « Gb r>), SGSN ^ GGSN 

(Interface « Gn ») 

Sur les interfaces « Gb » et « Gn » les PDUs sont routees connnne des 
poquets. Sur les interfaces « Abis » et radio, les PDUs sont transportees sur des 
canaux dedies. 

-10 Pendant le flux temps reel, les mesures radio reportees sont envoyes du MS 

au BSS sur le SACCH existant, Sur la base de ces mesures radio reportees, le BSS 
peut effectuer des « handovers » en utilisant les mecanismes existants. 
Sur la figure 6 : 

- I'etope 61 indique que Ketablissement d'un oppel est en cours pour un 
15 flux de media temps reel, le « Final SDP » vient d'etre envoye (dans le 

cas MO) ou regu (dans le cas MT), 

- I'etape 62 indique qu"un contexte PDP secondaire est cree dans le-, 
SGSN, 

- I'etape 63 indique que le BSS a regu une requete « PFC Creation : 
20 Request » pour un flux temps reel, il etablit des ressources dediees, 

- I'etape 64 indique que le MS active les ressources dediees allouees, 

- I'etape 65 indique qu'un fonctionnement en multi-trame est maintenant 
etabli, la contention est r^solue, et le BSS connaTt le TLLI de la nouyelle 
connexion. Un « handover » est efFectu6 si necessaire, 

25 - I'etape 66 indique que I'etablissement d'appel SIP peut alors se 

produire, 

- i'option correspondant 6 la premiere procedure indiquee plus haut a ete 
notee 67 

- I'option correspondant a la seconde procedure 5ndiqu6e plus haut a ete 
30 not6e 68. 

Les differents messages not6s sur la figure 6 : (P)RACH, PACKET UPLINK 
ASSIGNMENT, ACTIVATE PDP CONTEXT REQUEST (secondary PDP context), CREATE 
BSS PFC, CS PAGING (from the PS domain), IMMEDIATE ASSIGNMENT, SABM + 
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GPRS INFORMATION, UA + GPRS INFORAAATION, CREATE BSS PFC ACK , 
ACTIVATE PDP CONTEXT ACCEPT, ont ete soit rappeles soit d6finis prec6clemment 
Eventuellement, pour plus d'informations sur les messages ou procedures existants on 
pourra se reporter oux specifications correspondantes, pour ces systemes). 
5 On notera que rexemple ainsi d6crit ne constitue qu'un des exemples 

possibles de mise en oeuvre de Tinvention, On comprendra qu'il n'est pas possible 
de decrire ici tous les exemples de mise en oeuvre possibles, et que la presente 
invention est bien sOr d'appiication generate, et n'est pas limitee 6 cet exemple 
particulier. 

10 Un des avantages de ['invention est que les procedures ou protocoles 

existants sont r6-utilis6s, Notamment, il n'y a pas besoin d'introduire une nouvelle 
combinaison de canal, ni un « handover » de TBF. Les impacts sur une station mobile 
selon la version R99 de la norme supportant ie mode DTM (« Dual Transfer Mode ») 
sont reduits a un minimum (le contexte PDP pour lequel un canal dedie est alloue doit 

15 etre indique a la station mobile). II n'y a pas besoin de definir une nouvelle couche 
de protocole au-dessus de la couche RLC/MAC puisque la couche RR au-dessus de 
LAPDm peut etre re-utilisee. Toute la signalisation peut etre effectuee a trovers les 
canoux existants SACCH et FACCH. Ceci n'empeche pas d'ameliorer les procedures 
DTM existantes pour supporter des « handovers » simultanes de trafic temps reel 

20 transports dans des canaux dedies et de trafic non temps reel transports dans des 
canaux portages. Notamment invention permet d'introduire un support pour des 
sen/ices IMS dans le mode « A/Gb » du reseau GERAN a un cout minimum. 
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REVENDICATIONS 

1 . Proc6d6 pour supporter du trafic temps reel dans un systeme de 
radiocommunicotions mobiles comportant un reseau d'acces radio et un coeur de 
r6seau, proced6 dans lequel du trafic en temps r6el supporte en mode paquet dons 

5 le coeur de reseau est supporte en mode circuit dons le reseau d'acces radio. 

2. Proc6de salon la revendication 1, dans lequel ledit support de trafic temps 
reel en mode circuit dans le reseau d'acces radio inclut une allocation de canaux 
dedies, ladite allocation de canaux dedies etant effectuee a la creation d'un contexte 
de flux paquet (PFC). 

10 3. Procede selon la revendication 2, dans lequel ledit contexte de flux paquet 

est cree dans le reseau d'acces radio. 

4. Procede selon la revendication 3, dans lequel ledit contexte de flux paquet 
contient des paramfetres de QoS a offrir par le reseau d'acces radio et negoci6s avec 
le coeur de reseau. 

15 5. Procede selon I'une des revendi cations 1 a A, dans lequel ledit trafic' 

temps reel correspond d au moins un flux de media d'une session multimedia.' 
6. Procede selon I'une des revendications 16 5, dans lequel ladite 

allocation de canaux d6dies utilise une procedure d'ollocation comportant un 

« paging » suivi d'un acces au reseau. 
20 7, Procede selon I'une des revendications 1 a 5, dans lequel ladite V 

allocation de canaux dedies utilise une procedure deallocation directe. 

8. Procede selon I'une des revendications 1 a 7, dans lequel : 

une station mobile a laquelle des canaux dedi6s ont ainsi ete allou6s 
transmet au reseau des informations relatives a son identite, 
25 - sur la base de ces informations, le r6seau associe un contexte de flux 

paquet 6 cette station mobile, et , le cas 6cheant, une r6-allocation de canaux 
dedi6s est effectuee en vue de satisfaire la qualite de service requise pour cette station 
mobile. 

9. Equipement de reseau d'acc6s radio pour systeme de 

30 radiocommunicotions mobiles, comportant des moyens pour mettre en oeuvre un 
proced6 selon I'une des revendications 16 8. 
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10. Equipement de coeur de reseau pour systeme de radiocommunications 
mobiles, comportant des moyens pour mettre en oeuvre un precede selon I'une des 

revendications 16 8- 

1 1 . Station mobile pour systeme de radiocommunications mobiles^ 
5 comportant des moyens pour mettre en oeuvre un procdde selon I'une des 

revendications 1 a 8, 



10 
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